\section{Extensibility}
\label{sec:extend}

Extensibility in RSHC is enabled by the initial version handshake between the client and server, as detailed in \sect{sec:pdus:pdu:hs}:
\begin{itemize}
\item The client sends a poke message to the server, signaling it wishes to initiate communication
\item The server sends the highest version it supports to the client
\item The client sends the selected version (should be a valid one, up to the one received from the server)
\end{itemize}

The initial version discussed in this document, v1, follows the synchronous communication, which includes challenge-response authentication, followed by the {\tt init} message and finally the action-confirm / update messages. However, future versions can rely on that the communication starts with version decision and introduce new methodologies to all parts of the communication. Examples for extensions, which add states to the DFA and new messages, include but not limited to:
\begin{itemize}
\item New authentication schemes: instead of immediately going to the challenge-response exchange, the protocol can go through an authentication method exchange where the client can then choose from a set of methods, for instance challenge-response (like in v1), private-public key based authentication and others (perhaps even allow no authentication at all).
\item System registration: the current version relies on prior registration of users to the system, handled by the application / system administrator, and not through the RSHC protocol. new states can be added to the DFA that upon handshake allow new users to register, change password, reset the account etc.
\item Concurrent user management: since the protocol supports multiple clients in parallel, new control management schemes can be applied. For instance, a hierarchy of users can be adopted (administrators, system users etc.) and new message types can be added that allow temporary block of clients (should be available only to administrators). This will add a new state to the protocol in the communication phase, to which the protocol will be transitioned when the client is blocked, and returned from when it is released.
\end{itemize}

In addition to new states of the DFA (which derive new messages), new message types (or changes to existing messages) can be added to the DFA in the current version. The most prevalent addition is supporting new built-in types, in addition to the current lights, shades, aircons, TVs and alarms. Moreover, it is expected that a subsequent version of the protocol should support device types not built in to the protocol, i.e. custom devices defined by the server, as discussed next.

New device types can be supported by passing a device type description and a list of possible device type commands in the {\tt init} message.  With this information, the client can manipulate and query a new device just as easily as a built-in device.  For example, {\tt c5} completely specifies a custom device type: begins with the number of {\tt c5} devices (just like for preset devices), but follows device description, number of states and their description, number of parameters and their description, number of actions and their encodings, and finally actual instances information -- device names with their current state and parameter values. Note that we leave action encoding format for future development; however we note that it should include parameter information (number, size and order) and states at which the action is legal (the {\tt action enc. size} preceding the action encoding should manage delineation).

\begin{verbatim}
[0x03 : 1]
[n0=#lights: 1][name0: 16][state0: 1][params0: 1]
    ...[name n0: 16][state n0: 1][params n0: 1]
...
[n4=#alarms: 1][name0: 16][state0: 1]
    ...[name n4: 16][state n4: 1]
[c5=#type 1 devices: 1]
    // device description
    [device type description: 16]
    // # device states and their description
    [m=#state count: 1]
    [state0 desc.: 16][state1 desc.: 16]...[state m desc.: 16]
    // # device parameters and their description
    [p=#parameters: 1]
    [param0 desc.: 16][param1 desc.: 16]...[param p desc.: 16]
    // # device actions and their encoding
    [a=#action count: 1]
    [A0=action0 enc. size: 1][action0 enc.: A0]
    ...
    [Aa=action0 enc. size: 1][action0 enc.: Aa]
    // finally, name of instances of the device, their current state and params
    [name0: 16][state0: 1][param0,0: 1]...[param0,p: 1]
        ...[name c5: 16][state c5: 1][param c5,0: 1]...[param c5,p: 1]
\end{verbatim}

Since it is assumed the transport layer is reliable and connection oriented, new message types can be added by defining them in a subsequent version of the protocol. No assumptions are made about the DFA that must be carried over to a future version, therefore adding or modifying states is as simple as defining them. Of course, backward compatibility may be a goal of a future version. In that case it is recommended that the only way to enter a new state is with a new message type.
